I think we can make the share method static. Right now, we can only use SharePlus.instance, but I feel that using SharePlus.share would be more concise.

Nope :) that was the whole point of the refactor, to make SharePlus instantiable and not use static methods. We had reports that the old Share class was hard to mock/fake because of that so we are moving to this pattern where you can either create an instance of the class or use SharePlus.instance, which I have seen in other packages e.g. Firebase.

The title parameter is not supposed to be mandatory. If it’s set to an empty string, the feature might not work properly. For optional features like this, I don’t think it should be validated this way.

await SharePlus.instance.share(
      ShareParams(
        text: 'test',
        subject: '',
        title: '',
      ),
    );

When I share like this, the following exception occurs.
If the title is an empty string (''), can we just ignore it?

Unhandled Exception: PlatformException(error, Non-empty title expected, null, null)
#0 StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:648:7)
#1 MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:334:18)

#2 MethodChannelShare.share (package:share_plus_platform_interface/method_channel/method_channel_share.dart:25:20)

#3 DemoAppState._onShareWithResult (package:share_plus_example/main.dart:218:4)

Probably this comment was for line 288, as this if-condition is checking text, not title.

Title is not mandatory indeed. This could probably be done indeed, although I am not sure how the UI would behave with an empty string. I am fine to do this change afterward checking how the UI works in that case, I am not sure also if there is a usecase where the title should be an empty string as opposed to ignore it.

From what I see, when a uri is provided, the text becomes ineffective because uri is checked first. So I’m wondering if we could define a priority—for example, if a uri is passed, then text is ignored—instead of making the two parameters mutually exclusive.

I am replying about this question here: https://github.com/fluttercommunity/plus_plugins/pull/3404/files/bad0154682593755febf2ded51963c162edc6346#r2048771496

Can we define a priority? For example, if there’s a Uri, we can ignore the text. At the very least, let the user share successfully. Right now, directly aborting like this feels a bit too arbitrary.

SharePlus.instance.share(
      ShareParams(
        text: 'test',
        subject: '',
        title: '',
        uri: Uri.tryParse('https://google.com')
      ),
    );

Unhandled Exception: Invalid argument(s): uri and text cannot be provided at the same time
E/flutter (17265): #0 SharePlus.share (package:share_plus/share_plus.dart:78:7)
E/flutter (17265): #1 DemoAppState._onShareWithResult (package:share_plus_example/main.dart:218:29)
E/flutter (17265): #2 DemoAppState.build.. (package:share_plus_example/main.dart:167:33)
E/flutter (17265): #3 _InkResponseState.handleTap (package:flutter/src/material/ink_well.dart:1170:21)
E/flutter (17265): #4 GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:351:24)
E/flutter (17265): #5 TapGestureRecognizer.handleTapUp (package:flutter/src/gestures/tap.dart:656:11)
E/flutter (17265): #6 BaseTapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:313:5)
E/flutter (17265): #7 BaseTapGestureRecognizer.handlePrimaryPointer (package:flutter/src/gestures/tap.dart:246:7)
E/flutter (17265): #8 PrimaryPointerGestureRecognizer.handleEvent (package:flutter/src/gestures/recognizer.dart:703:9)
E/flutter (17265): #9 PointerRouter._dispatch (package:flutter/src/gestures/pointer_router.dart:98:12)
E/flutter (17265): #10 PointerRouter._dispatchEventToRoutes. (package:flutter/src/gestures/pointer_router.dart:143:9)
E/flutter (17265): #11 _LinkedHashMapMixin.forEach (dart:collection-patch/compact_hash.dart:633:13)
E/flutter (17265): #12 PointerRouter._dispatchEventToRoutes (package:flutter/src/gestures/pointer_router.dart:141:18)
E/flutter (17265): #13 PointerRouter.route (package:flutter/src/gestures/pointer_router.dart:127:7)
E/flutter (17265): #14 GestureBinding.handleEvent (package:flutter/src/gestures/binding.dart:501:19)
E/flutter (17265): #15 GestureBinding.dispatchEvent (package:flutter/src/gestures/binding.dart:481:22)
E/flutter (17265): #16 RendererBinding.dispatchEvent (package:flutter/src/rendering/binding.dart:450:11)
E/flutter (17265): #17 GestureBinding._handlePointerEventImmediately (package:flutter/src/gestures/binding.dart:426:7)
E/flutter (17265): #18 GestureBinding.handlePointerEvent (package:flutter/src/gestures/binding.dart:389:5)
E/flutter (17265): #19 GestureBinding._flushPointerEventQueue (package:flutter/src/gestures/binding.dart:336:7)
E/flutter (17265): #20 GestureBinding._handlePointerDataPacket (package:flutter/src/gestures/binding.dart:305:9)
E/flutter (17265): #21 _invoke1 (dart:ui/hooks.dart:328:13)
E/flutter (17265): #22 PlatformDispatcher._dispatchPointerDataPacket (dart:ui/platform_dispatcher.dart:442:7)
E/flutter (17265): #23 _dispatchPointerDataPacket (dart:ui/hooks.dart:262:31)
E/flutter (17265):

I prefer to take an offensive programming approach. My experience with this project tells me that users don't really read the documentation, and instead they go straight to the issue tracker to complain when something isn't as they expect, so letting users provide both text and uri will lead to users thinking both can be shared at the same time, instead I prefer that the package enforces providing data correctly.

From what I understand, in many scenarios, the content to be shared is not necessarily predetermined — it is decided at runtime or fetched from a server API. In such cases, both text and uri might be present. If I had to choose between (1) failing to share and (2) only sharing part of the content, I would definitely choose the latter. I believe our goal is to enable sharing. We should do everything we can to ensure the share succeeds, rather than blocking it just because the parameters don’t exactly meet our expectations.

I think we can leverage asser() to ensure the production environment while also restricting the development environment. I’m not sure if this would be better.

I see your point, and if it was an existing API, I would definitely go with asserts instead. I'd say we merge it like this and see how it goes, and depending on the feedback we can move it back.